In every project there are the people who want something and those who can implement this “will”. It is therefore very important that this “will” is pronounced appropriately. And nobody is better suited for this task than the one who is willing.

Requirements must be described precisely – they are the foundation of a project. But how can this be done correctly? How does a willing person manage to describe something for another person in such a way, so that this person can take measures in order to turn the desired requirement into reality? Or how to help a willing person to describe the requirements properly?

User Stories

User stories help to introduce structure into requirements. The quality – how well the requirement is described and if it is simple enough to understand for the person, who is supposed to implement it – depends upon the author of the user story. The more this person can identify with the user story, the better the story’s description is going to be. Therefore, it is recommended that the customer writes the user stories, for example, by entering entering them in a collective wiki (e.g. Confluence).

If the customer cannot or does not want to write a user story (which is usually the case) then these should be developed by a meeting with the customer. It is therefore advisable that the customer prepares himself, and that he, at least, describes individual requirements on an enumeration list. The requirements should then be processed in the meeting in a focussed manner and user stories should be created. A “golden rule” does not exist in this case; the only thing that does help is doing it.

Syntax of a User Story

A user story introduces a structure into a requirement; Therefore, I will start with the syntax:

#<Number> As <role> I want <goal>(, to ) <-- optional

If a user story cannot be described with this syntax then it is too large or too complex. In this case you have to try to separate the user story. Sometimes several user stories are hidden in one. Only common sense can help to recognize that and to separate it.

Example

This sentence:

As a user, I want to be able to log in with Facebook, Twitter, Google.

Becomes this:

As a user, I would like to be able to log in with Facebook.
As a user, I would like to be able to log in with Twitter.
As a user, I would like to be able to log in with Google.

A User Story’s semantics

A user story is thus divided into the following three parts:

• Role
• Goal
• Reason

Several components can be derived from this semantically, which are important for the later processung:

• Role | Goal
• Goal | Complexity | Effort
• Reason | Efficiency | Urgency

Every project should begin with the documentation of the user stories. Projects that adapt agile working methods should also document their user stories subsequently. It is important that these user stories can be entered, evaluated, and monitored as efficiently as possible with a tool.
The aspect of “as efficient as possible” is an important keyword here, because nobody is interested in creating additional expenses or to have friction losses through communication in the documentation of the user stories. Common tools such as Confluence or Jira are suited for this.

Tip: Use any tool to make your life easier.

User stories also help to ensure that everyone on the project team receives a proper briefing about the tasks that are to be accomplished. What used to be a difficult to read and long specification back then, is nowadays a user story, which everyone can understand and comprehend.

Furthermore, user stories help to speak one, if not the same, language with the customer. For instance, when we’re talking about the story #23.2, then everyone knows what is meant – or they can at least look it up in the documentation and understand what it is about. This is also called “ubiquitous language” (DDD developers will hate me now for stealing the term).

What is important:

1. The documentation of the user stories takes place.
2. The documentation of the user stories is efficient.
3. The documentation of the user stories is complete (the customer did not add further user stories).
4. The documentation of the user stories is uniform (in accordance to the syntax).
5. The documentation of the user stories is accessible to everyone (reading and writing).

Regarding the third point: It is of course possible that the customer comes up with further user stories later. But this is not a problem for the time being in the agile project organisation, because the customer can easily communicate the new user stories. However, it must be ensured that a user story’s communication does not resemble the direct implementation.

Example

We are going use the requirements of a fictional to-do-application to illustrate the documentation of user stories:

Here we have six different user stories present, prioritized by the customer. We always follow the syntax and number each user story. This list would now, for example, be entered into a common wiki (e.g. Confluence) and made accessible to everyone.

The order, in which the user stories are to be implemented, is the next step. With only 6 user stories this no problem at all. But if there are 100 user stories, then they have to be clustered somehow and have to be put in order. But even with only 6 user stories, the importance of the prioritization could be forced by stating that a release must be fulfilled within 2 weeks.

Milestone Prio

Due to the agile organisation of a project, it is possible to keep the requirements flexible during the implementation. Nevertheless, deadlines and dates exist in our world, on which a release must happen. However, agile methods are not designed with this in mind. They are, first and foremost, based on the assumption that Sprint is developing software for Sprint, without taking a look at the distant future.

A Milestone Prio does exactly that – it takes that look at the distant future, so that the customer can be told: “We’ll get the user story #1, #3, #5, …, #n done by 01.05 of this year”. The Milestone Prio is a meeting that is best attended by at least one person of each trade – design, product owner (PO), backend, frontend, concept, and more.

The team member should read the user stories to prepare themselves for the Milestone Prio.
The PO prepares the Milestone Prio by printing each user story on a DIN A5 (A6) sheet. The printout should have a margin of 2 to 3 cm, so that further notes can be made. Inside the frame, the use story number is written in the upper left corner. The Customer Prio is written in the upper right corner and below that in the rest of the space to the end of the frame the user story is written. The following figure shows such a sheet.

Fig.1: An exemplary user story from the Milestone Prio

The table should be completely cleared by the time the Milestone Prio takes place, so that you can do your work. Months or calendar weeks are written on papers of the relatively same size, and are put further below on the table (you can use sticky notes alternatively). Which scaling is used here depends on the project duration.

The team members go now through the individual user stories. They assign a thick dot to independent user stories in the top left corner of the frame, i.e. those that are not dependent on any other user story. If this user story can only be solved by one trade alone (mostly the implementation, such as technology), then a bold initial letter of said trade is put in the upper right corner.

Below the user story, the dependencies to other user stories are placed. The user story’s number and a short description (a few words) should always be available, so that you don’t have to look back and forth all the time. At this point there is no prioritizing yet.

In the next step, all user stories that have been assigned a Prio of 1 by the customer are placed on the far left side and below one another. All user stories without a dependency, i.e. the ones with a thick dot on their upper left side, are placed at the top left. All user stories with a dependency are placed below the independent Prio 1 user stories. The dependencies will now be resolved gradually. For example, if user story #5 has a dependency with user story #1, then user story #5 will be placed behind user story #1. If user story #3 has a lower priority than user story #1, but user story #1 is depending on #3, then it is placed before user story #1.

Common sense is important when handling the Milestone Prio, but there should also be enough room for creativity. If someone has an idea how to make the process more efficient then do it this way. If you think that the customer prioritization doesn’t make sense, you change it (but here the PO’s documentation is important as to why something has been changed).

Tip: Agility does not mean that everything is done according to a schema, but that one’s own approach is constantly reflected and improved (iterative and incremental).

Finally, one person from the team (usually the PO) documents all results and makes them available to everyone again.

Fig. 2: The Arrangement of User Stories in a Prio Meeting

We still keep to the to-do example. Here, all user stories were printed out and placed on the table. Below this, sticky notes were tagged with the month’s name and calendar weeks.

At the top left is the ticket on which all others depend. If there are several of such tickets, they can be grouped. The team has now worked out a prioritization together, where user story #1 is to be developed first, and apparently the team also manages #5 and #6 in sprint (two-week sprints).

Here we see that the priorities of the customer are taken into account and we get an outlook as to when the team could tackle various issues.

What is important: This is just a reasonable order of the user stories. The measurement of the individual user stories happens further down the course.

Planning Poker

Many customers want to hear about a specific figure: The figure that indicates how much the project is going to cost. This is a difficult to make commitment in the agile organisation of a project, because the project is supposed to be agile and can change spontaneously. This would be a contradiction in terms.

But what can be done, is to prioritize 80 out of 100 user stories and name an approximate price for those. This way, the customer can then decide if he is ready to pay for the 80 stories. It is important to inform the customer that the price is referring to the scope of the selected user stories. If the project is to become cheaper, the scope of the user stories is also reduced.

In order to provide the customer with a figure, the user stories have to be assessed. This works well with a Planning Poker.

Tip: Even during Planning Poker, it should always be kept in mind that estimates are only estimates and those never or rarely correspond to the actual value.

All team members sit down together during Planning Poker. Each team member receives purchased or homemade “Planning Poker” cards. Each card has a number of the Fibonacci series written on it (1, 2, 3, 5, 8, 13 …). The sheets of the user stories are brought back from the Milestone Prio by the product owner. Most of the team members were present at the Milestone Prio, therefore they should know the scope and the user stories.

Now, the team starts with the user stories that were in the top left corner in the Milestone Prio. The reason for that is that they are the first to be edited and that the following user stories are built upon them.

The user story is read out once again and the team member of a trade (e.g. design) explains, in relation to the user story, what needs to be done. Each team member then places a card on the table face down. This card is the assessment of hours or days (depending upon the scaling). All cards are revealed once each team member has placed a card. Now it is possible to see how well the collective estimation went. If the numbers deviate strongly from each other, it must be discussed why the numbers deviate. If the team members have agreed on a number, this is documented (table, Jira etc.). Now the other trades continue. This is done with all user stories.

From the documented figures, the PO can give an overall assessment by collecting all prioritized user stories from the Milestone Prio and all the user stories’ assessments.

The beauty of this process is that the PO can argue to the customer how these numbers came to be. This is why it is so important that the PO is present at both meetings and listens attentively or takes notes.

Now an offer (no invoice!) can be created. The table with the user stories can be added separately to the offer, whereby only the numbers of the user stories and the pertinent estimates are left in the offer. From this, a value can be computed with the hourly rate of the co-workers, which justifies the effort and the price.

Fixed prices vs. expenses accounts

A lot of customers still have the misconception that software projects can get managed with a fixed price. Either the customer wins, because the service provider then buckles at a low price and accumulates overtime, or the service provider wins, because the customer pays such a high price for a simple job.

Let’s take the fixed-price idea apart. It should also be mentioned at this point that we are not talking about finished products, i.e. software that is already finished and being further developed, but about new software that is to be implemented.

With a fixed price, the scope of the project is estimated and offset against the hourly rate of the employees. Here, the service provider enters into a commitment with the customer and vice versa. The customer receives a fixed price for a fixed scope, as does the service provider.

But here comes the problem: the fixed price is based on assessments and the scope is based on current willingness. If there was a way to plan software in advance in order to produce a number of minutes, then there would only be fixed prices. But since we are all human and our will can change and projects can increase in complexity, which is not taken into account in the assessment, fixed prices are equal to an estimate.

Thus the question arises: Can projects also be invoiced differently?

And the answer is: Yes.

There are expense accounts for that. In other words, an invoice in which the expenses are listed and thus settled. Therefore, it makes sense to document the times required for a user story thoroughly. These can then be attached to the invoice in a performance report, so that the customer can see where his money is going. Everything is transparent, everything is clear, based on trust.

If the customer wants to know in advance where his money will go to, an approximate assessment of the project can be named after the Planning Poker. The advantage over the fixed price for service providers is that if they should need more time for a particular user story, then they get paid as well.

However, the disadvantage over a fixed price is that the money does not flow until the work is done. In the case of fixed-price projects, the money flows much earlier, because the customer does get his product. It does not matter whether he pays now or afterwards.

Nevertheless, partial invoices can be created. For example, once a month so that money flows monthly. So, everything that has already been done can be billed. This gives the customer and the service provider the freedom to react. For example, if the customer’s money becomes scarce or the service provider has new employees, so that the scope can be increased: Agility over inflexibility.

Task Breakdown

If the customer has now accepted the offer and is aware of an approximate price and the scope, then the project can be started. From this point, agile methods like Scrum or Kanban blur with the previously prepared user stories.

But to really start with Scrum or Kanban, each trade has to create tasks (tickets) for itself. The PO does not know which steps are required to design a UI or set up the deployment of a project. The employees, who are going to do it by themselves, know this best. Thus, in ticket system (e.g. Jira), the user stories should already have been transferred, if this hasn’t happened yet. It is also important that not all tickets are created immediately, but that the tickets are best created in the Sprint planning, or a previous meeting, or simply entered as a task until the Sprint planning.
Agile methods, such as Scrum or Kanban, can be used from this point on.

Do not forget to do your retrospectives, this is important! Only with these you can reflect and, thereby, improve yourself.

Note: I use the generic masculine in this article. Of course, there can be a male, female or diverse person in every trade.

Thanks to Christopher S., who had the brilliant idea to dissolve the dependencies in the Milestone Prio.